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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The objective of this document is to address the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and 
Izi reference points between IMS networks in order to support end-to-end service interoperability. 

The present document will address the issues related to control plane signalling (3GPP usage of SIP and SDP protocols, 
required SIP headers) as well as other interconnecting aspects like security, numbering/naming/addressing and user 
plane issues as transport protocol, media and codecs actually covered in a widespread set of 3GPP specifications. A 
profiling of the Inter-IMS Network to Network Interface (II-NNI) is also provided. 

Charging aspects will be addressed as far as SIP signalUng is concerned. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 
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IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions, as specified in 3GPP TS 22.228 [9]. 

IP multimedia session: as specified in 3GPP TS 22.228 [9] an IP multimedia session is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers. IP multimedia sessions are supported by the IP 
multimedia CN Subsystem and are enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user may invoke 
concurrent IP multimedia sessions. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [120] apply: 

MSC Server enhanced for ICS 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ici Reference Point between an IBCF and another IBCF or I-CSCF belonging to a different IM CN 

subsystem network 
Izi Reference Point between a TrGW and another TrGW or media handling node belonging to a 

different IM CN subsystem network 
Mi Reference Point between a BGCF and CSCF 

Mm Reference Point between a CSCF/BGCF/IMS ALG and an IP multimedia network. 

Mw Reference Point between a CSCF and another CSCF 

Mx Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS and IBCF 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

ACR Anonymous Communication Rejection 

B2BUA Back 2 Back User Agent 

BGCF Breakout Gateway Control Function 

CAT Customized Alerting Tone 

CB Communication Barring 

CCBS Completion of Communications to Busy Subscriber 

CCNR Communication Completion on No Reply 

CDIV Communication Diversion 

CDIVN Communication Diversion Notification 

CRS Customized Ringing Signal 

ECT Explicit Communication Transfer 

FA Flexible Alerting 

HOLD Communication HOLD 

CW Communication Waiting 

IBCF Interconnection Border Control Function 

ICB Incoming Communication Barring 

ICS IMS Centralized ServicesI-CSCF Interrogating CSCF 

II-NNI Inter-IMS Network to Network Interface 

IM Instant Messaging 

IMS -ALG IMS AppUcation Level Gateway 

MCID Malicious Communication IDentification 

MRFC Media Resource Function Controller 

MSRP Message Session Relay Protocol 

MWI Message Waiting Indication 

NA(P)T-PT Network Address (Port-Multiplexing) Translation-Protocol Translation 

NNI Network to Network Interface 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy CSCF 
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PNM 

PRES 

TIP 

TIR 

TrGW 



Personal Network Management 

Presence 

Terminating Identification Presentation 

Terminating Identification Restriction 

Transition Gateway 



Overview 



Interconnection between two different IM CN subsystems shall be guaranteed in order to support end-to-end service 
interoperability. For this purpose, Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem 
networks is adopted, according to the assumptions coming from 3GPP TS 23.002 [3] and 3GPP TS 23.228 [4]. 

Aiming to support the delivery of IMS services between two separated IM CN subsystems, protocol interconnection has 
to occur: 

• at a control plane level, in order that IMS procedures can be supported. In this case the adopted reference point 
is the Ici; 

• at a user plane level, where media streams are exchanged over the Izi reference point. 

The management of IP multimedia sessions is acted by using SIP. The transport mechanism for both SIP session 
signalling and media transport is IPv4 (IETF RFC 791 [2]) or IPv6 (IETF RFC 2460 [7]). The 3GPP profile of SIP 
defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [5]. Example call flows are 
provided in 3GPP TR 24.930 [6]. 

The general interconnection model is shown in Figure 4.1. 




II-NNI 




Figure 4.1 : Interconnection Model for IM CN Subsystems 

The possible functional entities involved in the signalling plane interconnection (IBCF, I-CSCF, P-CSCF, BGCF and 
MSC Server enhanced for ICS) and in the user plane interconnection (TrGW) are specified in 3GPP TS 24.229 [5], in 
3GPP TS 29.292 [121] and in 3GPP TS 29.162 [8]. 

IP Version interworking is described within 3GPP TS 29.162 [8]. 



Reference model for interconnection between IIVI CN 
subsystems 



5.1 



General 



Figure 5.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter-IMS Network to Network 
Interface (II-NNI) between two IM CN subsystem networks. 
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P-CSCF 



MSC Server 

enhanced 

for ICS 




S-CSCF 

7 



*»^Mx 



^ 


P-CSCF 


^ 


Mx 






> 


MSC Server 

enhanced 

for ICS 





Signalling 

^^ IM CN subsystem network A IM CN subsystem network B 

Figure 5.1.1 : Inter-IMS Network to Network Interface between two IM CN subsystem networks 

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface. 

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and 
forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to 
forward media streams between IM CN subsystem networks. 

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. 

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks 
belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10]. 



5.2 Functionalities performed by entities at the edge of the 
network 

5.2.1 Interconnection Border Control Function (IBCF) 

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], it may act both as 
an entry point and as an exit point for a network. 

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]: they include: 

network topology hiding; 

application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or 
between a SIP application in a private IP address space and a SIP application outside this address space); 

controlling transport plane functions; 

controlling media plane adaptations; 

screening of SIP signalling information; 

selecting the appropriate signalling interconnect; 

generation of charging data records; 
Based on local configuration, the IBCF may perform transit routing functions [5]. 
The IBCF acts as a B2BUA when it performs IMS-ALG functionaUty. 

5.2.2 Transition Gateway (TrGW) 

According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled 
by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point. 
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The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds 
addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the 
two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport 
identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8]. 

Further details are described in 3GPP TS 23.228 [4]. 



6 Control plane interconnection 

6.1 Definition of Inter-IMS Network to Network Interconnection 

6.1 .1 SIP methods and headers 

6.1.1.1 General 

The functional entity closest to the border of an IMS network towards an Inter-IMS Network to Network 
Interconnection (see reference model in Clause 5) shall provide the capabilities specified for that network element in 
Annex A.2 of TS 24.229 [5] with modifications as described in the following sub-clauses. 

6.1.1.2 SIP methods 

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN 

subsystem. 

The following SIP Methods are supported on the II-NNI as defined in table 6.1. 

The following table is based on Table A.5 and Table A. 163 of TS 24.229 [5] and endorsed for this document: 



£75/ 



3GPP TS 29.165 version 9.2.0 Release 9 



16 



ETSI TS 129 165 V9.2.0 (2010-04) 



Table 6.1 : Supported methods 



Item 


Method 


Ret. 


ll-NNI 


Sending 


Receiving 


1 


ACK request 


[13] 


m 


m 


2 


BYE request 


[13] 


m 


m 


3 


BYE response 


[13] 


m 


m 


4 


CANCEL request 


[13] 


m 


m 


5 


CANCEL response 


[13] 


m 


m 


5A 


INFO request 


[28] 








5B 


INFO response 


[28] 








8 


INVITE request 


[13] 


m 


m 


9 


INVITE response 


[13] 


m 


m 


9A 


MESSAGE request 


[19] 








9B 


MESSAGE response 


[19] 








10 


NOTIFY request 


[20] 


Cl 


cl 


11 


NOTIFY response 


[20] 


Cl 


cl 


12 


OPTIONS request 


[13] 


m 


m 


13 


OPTIONS response 


[13] 


m 


m 


14 


PRACK request 


[18] 


m 


m 


15 


PRACK response 


[18] 


m 


m 


15A 


PUBLISH request 


[21] 


cl 


cl 


15B 


PUBLISH response 


[211 


cl 


cl 


16 


REFER request 


[22] 








17 


REFER response 


[22] 








18 


REGISTER request 


[13] 


c2 


c2 


19 


REGISTER response 


[13] 


c2 


c2 


20 


SUBSCRIBE request 


[201 


cl 


cl 


21 


SUBSCRIBE response 


[201 


cl 


cl 


22 


UPDATE request 


[23] 


m 


m 


23 


UPDATE response 


[23] 


m 


m 


c1 : In case of roaming scenario, tlie support of tlie metliod is m, else o. 
c2: In case of roaming scenario, the support of the method is m, else n/a. 


NOTE: In the above table, m, o and c and n/a have the meanings indicated in 
Table 6.3 



The methods described in Table 6.1 shall be passed transparently on the II-NNI. 

6.1.1.3 SIP headers 



6.1.1.3.0 



General 



The IBCF shall provide the capabilities to manage and modify SIP headers according to section 5.10 and Annex A of 
TS 24.229 [5] with modifications as described in the following sub-clauses. 



6.1.1.3.1 



Trust and no trust relationship 



The IBCF acting as exit point shall apply the procedures described in clause 5.10.2 of TS 24.229 [5] before forwarding 
the SIP signalling to the IBCF acting as entry point; this one shall apply the procedures described in clause 5.10.3 of TS 
24.229 [5]. 

Additionally, in case there is no trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF 
acting as exit point shall apply the procedures described in clause 4.4 of TS 24.229 [5], before forwarding the SIP 
signalling to the next IBCF. 

These procedures may be utilized on a per header basis to realize overall trust as well as per service level screening of 
headers. Trust relationships and trust domains may be defined by inter-operator agreements for individual services 
and/or individual SIP headers. 

The management of the SIP headers (if present) over II-NNI in case of a presence or not of a trust relationship between 
the two interconnected IM subsystems is wrapped up in the following table. 
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Table 6.2: Management of SIP headers over ll-NNI in presence or not of a trust relationship 



Item 


Header 


Trust relationship 


Not trust relationship 


1 


P-Asserted-ldentity 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
and Annex J. 2 


As specified in 3GPP TS 
24.229 [5], clause 4.4 and 
Annex J. 2 


2 


P-Access-Network- 1 nfo 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


3 


Resource-Priority 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


4 


History-Info 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in Clause 4.3.3 of 
RFC 4244 [25] and in 3GPP 
TS 24.229 [5], clause 4.4 


5 


P-Asserted-Service 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


6 


P-Charging-Vector (see RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


7 


P-Charging-Function-Addresses (see 
RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


8 


P-Profile-Key 
(NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


9 


P-Private-Network-lndication 
(N0TE1) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


10 


P-Served-User 
(NOTE 1 , NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


11 


Reason (in a response) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


12 


P-Early-Media 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


NOTE 1 : For a roaming ll-NNI between a home IMS and a visited IIVIS, a trust relationship with respect to this 

header is required. 
NOTE 2: This header is only applicable on an ll-NNI between a home IMS and a visited IMS. 
NOTE 3: In addition, value-dependent operator policies may be applied. 



6.1.1.3.2 



Derivation of applicable SIP headers from TS 24.229 



For any method in Table 6.1, the SIP headers applicable on the II-NNI are detailed in the corresponding method tables 
for the UA role and proxy role sending behaviour in Annex A of 3GPP TS 24.229 [5]. Unless other information is 
specified in the normative part of the present specification, the applicability of headers at the II-NNI can be derived for 
each method from the corresponding tables in Annex A of 3GPP TS 24.229 [5] as follows: 

All headers not present in the corresponding tables in Annex A of 3GPP TS 24.229 or marked as 'n/a' in both the 
'RFC status' and 'profile status' columns for the UA role and proxy role sending behaviour of that tables are not 
applicable at the II-NNI. 

NOTE 1: Operators could choose to apply headers for new SIP extensions on an II-NNI based on bilateral 
agreements, but this is outside the scope of the present specification. 

All headers which are marked as 'o' in at least one of the 'RFC status' or the 'profile status' profile columns for the 
sending behaviour in the corresponding UA role and proxy role tables in Annex A of 3GPP TS 24.229 and as 
'n/a' or 'o' in the other such columns are applicable at II-NNI based on bilateral agreement between operators. 

All headers which are marked as 'm' in at least one of the 'RFC status' or the 'profile status' columns for the 
sending behaviour in the corresponding UA role or proxy role table in Annex A of 3GPP TS 24.229 and as 'n/a', 
'o', or 'm' in the other such columns are applicable at the II-NNI. 
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If conditions are specified, they are also applicable at the II-NNI and the above rules are applicable to the 'n/a', 'o' 
and 'm' values within the conditions. 

NOTE 2: In the above rules, the RFC profile columns are taken into account in order to enable interworking with 
non-3GPP networks. 

An informative summary of SIP headers to be used over the II-NNI is proposed in Annex A. 

6.1 .1 .3.3 Applicability of SIP headers on a roaming II-NNI between home IMS and visited 
IMS 

The following SIP headers are not applicable on a roaming II-NNI between a home IMS and a visited IMS: 
Proxy- Authentication 
Proxy- Authorization 

6.1 .1 .3.4 Applicability of SIP headers on an II-NNI between home IMS networks 

The following SIP headers are not applicable on an II-NNI between home IMS networks: 

- P-Called-Party-ID 
P-Preferred-Service 

- P-Profile-Key 
P-Served-User 

- P-Visited-Network-ID 

- WWW-Authenticate 

6.1.1.4 Notations of the codes 

In the table 6.1 the status codes m, o, c, i and n/a have the following meanings: 

Table 6.3: Key to notation codes for SIP messages 



Notation 
code 


Notation name 


Sending side 


Receiving side 


m 


mandatory 


The message shall be supported at II- 
NNI. 

Supporting sending a SIP message at 
the II-NNI means that this message shall 
be sent over the II-NNI if received from 
the serving network. It does not imply 
that network elements inside the serving 
network or user equipment connected to 
this network shall support this message. 


Supporting receiving a SIP message at 
the II-NNI means that this message shall 
be forwarded to the serving network. It 
does not imply that network elements 
inside the served network or user 
equipment connected to this network are 
supporting this message. 





optional 


The message may or may not be 
supported at II-NNI. The support of the 
method is provided based on bilateral 
agreement between the operators. 


Same as for sending side. 


n/a 


not applicable 


It is impossible to use/support the 
message. 


It is impossible to use/support the 
message. This message will be 
discarded by the IBCF. 


c 
<integer> 


conditional 


The requirement on the message ("m", 
"o" or "n/a") depends on the support of 
other optional or conditional items. 
<integer> is the identifier of the 
conditional expression. 


Same as for sending side. 
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6.1.1.5 Modes of signalling 

Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used, 
otherwise enbloc shall be used at the NNI. 

6.1.2 SDP protocol 
6.1.2.1 General 

The functional entity closest to the border of an IMS network towards an Inter-IMS Network to Network 
Interconnection (see reference model in Clause 5) shall provide the capabilities specified for that network element in 
Annex AJofTS 24.229 [5]. 

6.1.3 Major capabilities 

This subclause contains the major capabilities to be supported over the II-NNI. 

The following table 6.1.3.1 specifies which capabilities are applicable for II-NNI. The profile status codec within table 
6.1.3.1 are defined in table 6.1.3.2. 

For the "Basic SIP" capabilities part of table 6.1.3.1, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the IETF RFC 3261 [13] main mechanisms described in the 2"** column "Capability over the 
Ici". 

For the "Extensions to basic SIP" capabilities part, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the RFC referenced in the 2nd column "Capability over the Ici". 

If necessary, the applicability of RFCs at the II-NNI level is further detailed in the present Technical Specification. 

The columns "Reference item in 3GPP TS 24.229 [5] for the profile status" provide informative references for 
comparison purposes into the UA and Proxy role major capabilities tables in 3GPP TS 24.229 [5], where the 
capabilities are defined via additional references. 
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Table 6.1.3.1 : Major capabilities over ll-NNI 



Item 


Capability over the lei 


Reference item in 3GPP 

TS 24.229 [5] for the 

profile status 


Profile 

status over 

ll-NNI 


UA Role 
(N0TE1) 


Proxy role 
(NOTE 2) 




Basic SIP (IETF RFC 3261 [13]) 








1 


registrations 


1,2, 2A 


- 


c2 


2 


initiating a session 


2B, 2C, 3,4 


- 


m 


3 


terminating a session 


5 


3 


m 


4 


General proxy behaviour 


- 


4,5, 14, 15, 
19F 


n/a 


5 


Forking of initial requests 


9,10 


6 


m 


6 


support of indication of TLS connections in the Record-Route 
header 


- 


7,8 


n/a 


7 


usage of http authentication 


7, 8, 8A 


8A 


c2 


8 


Timestamped requests (Timestamp header) 


6 


- 


m 


9 


Presence of date in requests and responses (Date header) 


11 


9 


m 


10 


Presence of alerting information data (Alert-info header) 


12 


10 





11 


Support and handling of the Require header for REGISTER 
and other requests or responses for methods other than 
REGISTER 




11, 12, 13 


m 


12 


Support and reading of the Supported and Unsupported 
headers 


- 


16, 17, 18 


m 


13 


Support of the Error-Info header in 3XX, 4XX, 5XX, 6XX 
responses 


- 


19 





14 


Support and handling of the Organization header 


- 


19A, 19B 


m 


15 


Support and handling of the Gall-Info header 


- 


19C, 19D 


m 


16 


Support of the Contact header in 3XX response 


- 


19E 


m 




Extensions to basic SIP 








17 


draft-ietf-sipcore-info-events-07 [39]: SIP INFO method and 
package framework 


13 


20 





18 


IETF RFC 3262 [18]: reliability of provisional responses in 
SIP (PRACK method) 


14 


21 


m 


19 


IETF RFC 3515 [22]: the SIP REFER method 


15 


22 





20 


IETF RFC 3312 [40] and RFC 4032 [41]: integration of 
resource management and SIP (Preconditions framework) 


16 


23 





21 


IETF RFC 331 1 [23]: the SIP UPDATE method 


17 


24 


m 


22 


IETF RFC 3313 [42]: SIP extensions for media authorization 
(P-Media-Authorization header) 


19 


26 


n/a 


23 


IETF RFC 3265 [20]: SIP specific event notification 
(SUBSCRIBE/NOTIFY methods) 


20,21,22, 
23 


27,28 


Cl 


24 


IETF RFC 3327 [43]: session initiation protocol extension 
header field for registering non-adjacent contacts (Path 
header) 


24 


29 


c2 


25 


IETF RFC 3325 [44]: private extensions to the Session 
Initiation Protocol (SIP) for network asserted identity within 
trusted networks 


25 


30, 30A, 
30B, 30C 


c4 


26 


IETF RFC 3325 [44]: the P-Preferred-ldentity header 
extension 


- 


- 


n/a 


27 


IETF RFC 3325 [44]: the P-Asserted- Identity header 
extension 


- 


- 


c4 


28 


IETF RFC 3323 [34]: a privacy mechanism for the Session 
Initiation Protocol (SIP) (Privacy header) 


26, 26A, 
26B, 26C, 
26D, 26E, 
26F, 26G, 
26H 


31,31A, 
31B, 31C, 
31D, 31E, 
31F, 31G, 
31H 


m 


29 


IETF RFC 3428 [19]: a messaging mechanism for the 
Session Initiation Protocol (SIP) (MESSAGE IVIethod) 


27 


33 





30 


IETF RFC 3608 [45]: session initiation protocol extension 
header field for service route discovery during registration 
(Service-Route header) 


28 


32 


c2 


31 


IETF RFC 3486 [46]: compressing the session initiation 
protocol 


29 


34 


n/a 


32 


IETF RFC 3455 [24]: private header extensions to the 
session initiation protocol for the 3rd-Generation Partnership 


30 


35 
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Project (3GPP) 








33 


IETF RFC 3455 [24]: the P-Associated-URI header extension 


31 


36 


c2 


34 


IETF RFC 3455 [24]: the P-Called-Party-ID header extension 


32 


37 


c2 


35 


IETF RFC 3455 [24]: the P-Visited-Network-ID header 
extension 


33 


38,39 


c2 


36 


IETF RFC 3455 [24]: the P-Access-Network-lnfo header 
extension 


34 


41,42,43 


c4 


37 


IETF RFC 3455 [24]: the P-Charging-Function-Addresses 
header extension 


35 


44, 44A 


n/a 


38 


IETF RFC 3455 [24]: the P-Charging-Vector header 
extension 


36 


45,46 


c2 


39 


IETF RFC 3329 [47]: security mechanism agreement for the 
session initiation protocol 


37 


47 


n/a 


40 


IETF RFC 3326 [48]: the Reason header field for the session 
initiation protocol 


38 


48 





41 


draft-jesske-dispatch-reason-in-responses-01 [49]: use of the 
Reason header field in Session Initiation Protocol (SIP) 
responses 


38A 


48A 


c4 


42 


IETF RFC 3581 [50]: an extension to the session initiation 
protocol for symmetric response routeing 


39 


49 





43 


IETF RFC 3841 [51]: caller preferences for the session 
initiation protocol (Accept-Contact, Reject-Contact and 
Request-Disposition headers) 


40, 40A, 
40B, 40C, 
40D, 40E, 
40F 


50, 50A, 
50B, 50C, 
50D, 50E, 
50F 


m 


44 


IETF RFC 3903 [21]: an event state publication extension to 
the session initiation protocol (PUBLISH method) 


41 


51 


Cl 


45 


IETF RFC 4028 [52]: SIP session timer (Session-Expires and 
IVIin-SE headers) 


42 


52 


m 


46 


IETF RFC 3892 [53]: the SIP Referred-By mechanism 


43 


53 


m 


47 


IETF RFC 3891 [54]: the Session Inititation Protocol (SIP) 
"Replaces" header 


44 


54 





48 


IETF RFC 391 1 [55]: the Session Inititation Protocol (SIP) 
"Join" header 


45 


55 





49 


IETF RFC 3840 [56]: the callee capabilities 


46 


56 





50 


IETF RFC 4244 [25]: an extension to the session initiation 
protocol for request history information (History-Info header) 


47 


57 


c4 


51 


IETF RFC 5079 [57]: Rejecting anonymous requests in the 
session initiation protocol 


48 


58 





52 


IETF RFC 4458 [58]: session initiation protocol URIs for 
applications such as voicemail and interactive voice 
response (NOTE 3) 


49 


59 





53 


IETF RFC 4320 [59]: Session Initiation Protocol's (SIP) non- 
INVITE transactions 


50 


61 


m 


54 


IETF RFC 4457 [60]: the P-User-Database private header 
extension 


51 


60 


n/a 


55 


IETF RFC 5031 [61]: a uniform resource name for services 


52 


62 


n/a 


56 


IETF RFC 5627 [62]: obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


53 


63 


cl 


57 


draft-patel-dispatch-cpc-oli-parameter-02 [63]: an extension 
to the session initiation protocol for request cpc information 


54 


64 


c4 


58 


IETF RFC 4168 [27]: the Stream Control Transmission 
Protocol (SCTP) as a Transport for the Session Initiation 
Protocol (SIP) 


55 


65 





59 


IETF RFC 5002 [64]: the SIP P-Profile-Key private header 
extension 


56 


66, 66A, 
66B 


c3 


60 


IETF RFC 5626 [65]: managing client initiated connections in 
SIP 


57 


67 


cl 


61 


draft-ietf-sip-ice-option-tag-02 [66]: indicating support for 
interactive connectivity establishment in SIP 


58 


- 


n/a 


62 


IETF RFC 5365 [67]: multiple-recipient MESSAGE requests 
in the session initiation protocol 


59 


69 


if 29, else 
n/a 


63 


draft-ietf-sipcore-location-conveyance-02 [68]: SIP location 
conveyance (Geolocation header) 


60 


70, 70A, 
70B 


m 


64 


IETF RFC 5368 [69]: referring to multiple resources in the 
session initiation protocol 


61 


71 


if 19, else 
n/a 


65 


IETF RFC 5366 [70]: conference establishment using 
request-contained lists in the session initiation protocol 


62 


72 
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66 


IETF RFC 5367 [71]: subscriptions to request-contained 
resource lists in the session initiation protocol 


63 


73 


if 23, else 
n/a 


67 


IETF RFC 4967 [72]: dialstring parameter for the session 
initiation protocol uniform resource identifier 


64 


74 


c2 


68 


IETF RFC 4964 [73]: the P-Answer-State header extension 
to the session initiation protocol for the open mobile alliance 
push to talk over cellular 


65 


75 





69 


IETF RFC 5009 [74]: the SIP P-Early-Media private header 
extension for authorization of early media 


66 


76 


m 


70 


IETF RFC 4694 [75]: number portability parameters for the 
"tel" URI 


67, 67A, 
678 


77, 77A, 
778 





71 


draft-yu-tel-dai-08 [76]: DAI Parameter for the "tel" URI 


68 


78 





72 


IETF RFC 441 1 [77]: extending the session initiation protocol 
Reason header for preemption events 


69 


79 





73 


IETF RFC 4412 [78]: communications resource priority for 
the session initiation protocol? (Resource-Priority header) 


70, 70A, 
70B, 70C, 
70D, 70E, 
70F, 70G 


80, 80A, 
80B, 80C, 
80D, 80E, 
80F, 80G 


c4 


74 


IETF RFC 5393 [79]: addressing an amplification 
vulnerability in session initiation protocol forking proxies 


71 


81 


m 


75 


IETF RFC 5049 [80]: the remote application identification of 
applying signalling compression to SIP 


72 


82 


n/a 


76 


IETF RFC 5688 [81]: a session initiation protocol media 
feature tag for MIME application sub-types 


73 


83 


Cl 


77 


draft-drage-sipping-service-identification-03 [26]: 
Identification of communication services in the session 
initiation protocol 


74 


84, 84A 





78 


IETF RFC 5360 [82]: a framework for consent-based 
communications in SIP? 


75, 75A, 
75B 


85 





79 


draft-johnston-sipping-cc-uui-08 [83]: transporting user to 
user information for call centers using SIP? 


76 


86 


cl 


80 


draft-vanelburg-dispatch-private-network-ind-00 [84]: The 
SIP P-Private-Network-lndication private-header (P-Header) 


77 


87 


cl 


81 


IETF RFC 5502 [85]: the SIP P-Served-User private header 


78 


88 


c2 


83 


draft-dawes-sipping-debug-02 [87]: the P-Debug-ID header 
extension 


80 


90 





84 


draft-ietf-sipcore-1 99-02 [88]: the 199 (Early Dialog 
Terminated) response code) 


81 


91 


m 


85 


IETF RFC 5621 [89]: message body handling in SIP 


82 


92 


m 


86 


draft-holmberg-sip-keep-04 [90]: indication of support for 
keep-alive 


83 


93 





87 


IETF RFC 5552 [91]: SIP Interface to VoiceXML Media 
Services 


84 


94 


n/a 


88 


IETF RFC 3862 [92]: common presence and instant 
messaging (CPIM): message format 


85 


95 





89 


IETF RFC 5438 [93] : instant message disposition notification 


86 


96 





90 


IETF RFC 5373 [94]: requesting answering modes for SIP 
(Answer-Mode and Priv-Answer-Mode headers) 


87 


97, 97A 





91 


draft-patel-ecrit-sos-parameter-08 [95]: SOS URI parameter 
for marking SIP requests related to emergency calls 


88 


98 


n/a 


92 


IETF RFC 3959 [96]: the early session disposition type for 
SIP 


89 


99 





93 


draft-rosenberg-sipcore-target-uri-delivery-01 [97]: delivery of 
Request-URI targets to user agents 


90 


100 


n/a 


94 


draft-kaplan-sip-session-id [124]: The Session-ID header 


91 


101 





95 


draft-ietf-sipcore-invfix-00 [125]: correct transaction handling 
for 200 responses to Session Initiation Protocol INVITE 
requests 


92 


102 


m 


96 


IETF RFC 5658 [126]: addressing Record-Route issues in 
the Session Initiation Protocol (SIP) 


93 


103 





97 


draft-ietf-sip-ipv6-abnf-fix-03 [127]: essential correction for 
IPv6 ABNF and URI comparison in IETF RFC 3261 [13] 


94 


104 


m 


c1 : m in case of roaming NNI between home and visited IIVIS, else o 

c2: m in case of roaming NNI between tiome and visited IMS, else n/a 

c3: in case of roaming NNI between home and visited IMS, else n/a 

c4: m in case of trust relationship between the interconnected networks, else n/a 


NOTE 1 : the item numbering corresponds to the one provided in Table A.4 in [5] 
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NOTE 2: the item numbering corresponds to the one provided in Table A. 162 in [5] 
NOTE 3: a common URI namespace is required to apply this feature on the ll-NN 



Table 6.1.3.2: Key to notation codes for major capabilities 



Notation 
code 


Notation name 


Explanation 


m 


mandatory 


The capability shall be supported at ll-NNI. 

SIP message relating to this capability shall be sent over the ll-NNI if received from 

the serving network, unless they also make use of other unsupported capabilities. 

SIP headers or other information elements relating to this capability shall be passed 

over the ll-NNI if received from the sending side. 

This does not imply that network elements inside the serving network or served 

network or user equipment connected to these networks shall support this capability. 





optional 


The capability may or may not be supported at ll-NNI. The support of the capability is 
provided based on bilateral agreement between the operators. 


n/a 


not applicable 


It is impossible to use/support the capability at the ll-NNI. 


c 
<integer> 


conditional 


The support of the capability ("m", "o" or "n/a") depends on the support of other 
optional or conditional items. <integer> is the identifier of the conditional expression. 



6.2 Control Plane Transport 
6.2.1 General 

The control plane transport of the IMS Inter-Operator Service Interconnection Interface shall comply with Clause 4.2A 
ofTS 24.229 [5]. 

Support of SCTP as specified in RFC 4168 [27] is optional for an IBCF connected by II-NNI. Nevertheless this option 
is favourable if the operators would like to improve reliability over the Ici. 



User plane Interconnection 



7.1 



Media and Codec 



For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between 
IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because 
no common codec could be supported by the UEs, in particular for voice services. 

To enhance interoperability, the IBCF, the MRFC, or other IMS network entities can interfere with the end-to-end 
codec negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure 
an attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode. 

Codecs applicable at the NNI may be a subject of interworking agreements. 

NOTE: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26. 1 14 [ 1 1 ] and ETSI TS 

181 005 [12]. 

However, to avoid that transcoding is performed several times, applicable codecs at the NNI should be restricted as 
little as possible. 

NOTE: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving 
an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can 
clarify if it is preferred that IMS network serving an SDP offerer or IMS network serving an SDP 
answerer modify an SDP offer to offer transcoding. 

If the IBCF performs media transcoding control, it shall apply the related procedures in 3GPP TS 24.229 [5]. 



£75/ 



3GPP TS 29.165 version 9.2.0 Release 9 



24 



ETSI TS 129 165 V9.2.0 (2010-04) 



7.2 User Plane Transport 

The user plane transport of the IMS Inter-Operator Service Interconnection Interface may use the protocols listed in 
Table 7.2.1. The used protocols to transport media are negotiated by means of SDP offer/answer. 

Table 7.2.1 : Supported transport-level RFCs to be described in SIP/SDP messages 



Item 


RFC 


Title 


Support 


1 


RFC 3550 


RTP: A Transport Protocol for Real-Time Applications 


Mandatory 


2 


RFC 768 


User Datagram Protocol 


Mandatory 


3 


RFC 3551 


RTP Profile for Audio and Video Conferences with Minimal 
Control 


Mandatory 


4 


RFC 3556 


Session Description Protocol (SDP) Bandwidth IVIodifiers for 
RTP Control Protocol (RTCP) Bandwidth 


Mandatory 


5 


RFC 4585 


Extended RTP Profile for Real-time Transport Control Protocol 
(RTCP) - Based Feedback (RTP/AVPF) 


Optional 
(N0TE1) 


6 


RFC 793 


Transmission Control Protocol 


Optional 
(NOTE 2) 


NOTE 1 : used by MTSI, as indicated in 3GPP TS 26.1 14 [11] 
NOTE 2: used for MSRP service 



8 Numbering, Naming and Addressing 

The following URI formats in SIP messages may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• SIP URI defined in IETF RFC 326 1 [ 1 3] ; 

• tel URI defined in IETF RFC 3966 [ 14] ; 

• IM URI defined in IETF RFC 3860 [15]; 

• PRES URI defined in IETF RFC 3859 [16]. 

Moreover, in case of MSRP sessions passing through the II-NNI, the MSRP URI may be also used at the Ici in the SDP 
exchange, following the formats defined in IETF RFC 4975 [17]. 

The IBCF shall support these URI formats. Other URI formats may be supported over the II-NNI depending on the 
operators" policies. 

A global number as defined in IETF RFC 3966 [14] shall be used in a tel-URI or in the user portion of a SIP URI with 
the user=phone parameter when conveyed via a non-roaming interface in the Request-URI and in the P-Asserted- 
Identity header, except when agreement exists between the operators to also allow other kinds of numbers. 

NOTE 1 : In a SIP URI the user portion of the Request-URI represents a telephone number only if the SIP URI 
includes user=phone parameter. 

NOTE 2: Agreements can exist between operators to allow non-global number (e.g. national service numbers. 

business trunking numbers, or private numbers) at a non-roaming II-NNI. A SIP URI with such a number, 
user=phone, and a phone context agreed between the operators can then be used. 

NOTE 3: 3GPP TS 24.229 [5] allows to restrict the number within a SIP Request-URI with user=phone at a non- 
roaming II-NNI to be a global number (i.e. E.164 in international format) via an appropriate Application 
Server. Suitable configuration by the operator is needed to achieve the desired modification of the format. 

NOTE 4: The allowed phone number formats in the P-Asserted-Identity header field of a served user are configured 
by the operator. According to 3GPP TS 23.003 [35], international E.164 format is used within a P- 
Asserted-Identity header field. 

NOTE 5: The global number format usage within a SIP Request-URI with user=phone at a non-roaming II-NNI 
allows the terminating network to find the called subscriber, via HSS interrogation, without any further 
number translation and thus improves the success of the interconnection between IMS Operators. 
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IP Version 



The network elements interconnected by means of the II-NNI may support IPv4 only, IPv6 only or both. 

The support of one or both of the IP versions is an operator option and should be based on bilateral agreement. 

In case IPv4 and IPv6 networks are interconnected, the involved IBCFs and TrGWs shall apply the IP version 
interworking procedures as indicated in 3GPP TS 29.162 [8]. 



10 Security 



The supported security mechanisms for IP signalling transport over II-NNI interfaces are described in 3GPP TS 33.210 
[10]. 



1 1 Charging 



The accounting information to be supported over the Ici is described in 3GPP TS 32.260 [29]. It shall be configurable 
by the operator to use or not the accounting mechanisms provided by the IBCF. 



12 Supplementary services associated with the IIVIS 
multimedia telephony communication service 

12.1 General 

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), 
associated supplementary services of the multimedia telephony communication service may be supported on the II-NNI 
between the two IMS networks. If they are supported, the related procedures from the 3GPP TS 22.173 [30], the 
protocol details from the 3GPP TS 24.173 [31] and specifications referenced in the later specification shall be applied 
with the following restrictions due to the crossing of the II-NNI. 

12.2 Malicious Communication IDentification (MCID) 

Service specific requirements in accordance with 3GPP TS 24.616 [33] shall be supported over the II-NNI. 

The INFO request and the 200 (OK) response to the INFO request containing the application/vnd.etsi.mcid-nxml body 
defined in 3GPP TS 24.616 [33] may be supported at the II-NNI. 

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the 
mcid-Hxml body, as specified in the 3GPP TS 24.616 [33], if an agreement to use the MCID supplementary service 
according to the 3GPP TS 24.616 [33] exists with the network originating the dialog and if the INVITE request received 
by the terminating network does not contain the information of the originating party. 

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an 

agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [33] and 3GPP 
TS 24.229 [5]. 

12.3 Originating Identification Presentation (OIP) and Originating 
Identification Restriction (OIR) 

Service specific requirements in accordance with 3GPP TS 24.607 [32] shall be supported over the II-NNI. 
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The P-Asserted-Identity header and the Privacy header with values "id", "user", "none" and "header" shall be supported 
at the II-NNI. 

Editor's Note: The handling of the "critical" value of the Privacy header field is ffs. 

NOTE 1 : P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header between the two IMS networks, this header cannot be altered when 
passing through the II-NNI according to 3GPP TS 24.229 [5]. Where no trust relationship exists on the P- 
Asserted-Identity header between the two IMS networks, the P-Asserted-Identity header will be removed 
by the IBCF of the originating network prior passing through the II-NNI according to the 3GPP TS 
24.229 [5]. The IBCF determines whether to remove the P-Asserted-Identity header field according to 
RFC 3325 [128]. 

NOTE 2: The From header cannot be altered when passing through the II-NNI and will be passed transparently by 
the IBCF. If a request is received by the terminating network and the application of the OIR service is 
required with the value "user" for the Privacy header then the From header will be anonymised in 
accordance with RFC 3323 [34] by the terminating network. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.4 Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) 

Service specific requirements in accordance with 3GPP TS 24.608 [113] shall be supported over the II-NNI. 

The P-Asserted-Identity header and the Privacy header with values "id", "user", "none" and "header" shall be supported 
at the II-NNI. 

Editor's Note: The handling of the "critical" value of the Privacy header field is ffs. 

NOTE : P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header between the two IMS networks, this header cannot be altered when 
passing through the II-NNI according to 3GPP TS 24.229 [5]. 

Where no trust relationship exists on the P-Asserted-Identity header between the two IMS networks, the 
P-Asserted-Identity header will be removed by the IBCF of the originating network prior passing through 
the II-NNI according to the 3GPP TS 24.229 [5]. The IBCF determines whether to remove the P- 
Asserted-Identity header field according to RFC 3325 [128]. 

12.5 Anonymous Communication Rejection (ACR) 

Service specific requirements in accordance with 3GPP TS 24.611 [107] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 433 (Anonymity Disallowed) shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.6 Communication Diversion (CDIV) 

Service specific requirements in accordance with 3GPP TS 24.604 [1 17] shall be supported over the II-NNI. 

NOTE 1 : The support of the Diversion header not adopted in 3GPP TS 24.604 requires bilateral agreement between 
the operators. Procedures as described in subclause 12.21.2 are used to provide announcements. 

The History-Info header as described by 3GPP TS 24.604 [117] and the Cause-Codes as defined by the 
IETF RFC 4458 [118] shall be supported over the II-NNI. 
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The response code 181 (Call Is Being Forwarded) shall be supported at the II-NNI. The SUBSCRIBE requests with the 
event package name "comm-div-info" and the NOTIFY request procedure as specified in IETF RFC 3265 [20] and 
3GPP TS 24.229 [5] shall be supported at the roaming II-NNI if CDIVN is provided. 

The MESSAGE request procedure as specified in IETF RFC 3428 [19] and 3GPP TS 24.229 [5] should be supported at 
the roaming II-NNI if CDIVN is provided. 

NOTE 2: The content of the MESSAGE request is operator specific. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.7 Communication Waiting (CW) 

Service specific requirements in accordance with 3GPP TS 24.615 [37] shall be supported over the II-NNI. 

The INVITE method containing the application/vnd.3gpp.cwH-xml body defined in 3GPP TS 24.615 [37] shall be 
supported at the roaming II-NNI. 

The Alert-Info header set to "urn:alert:service:call-waiting" in a 180 (Ringing) response shall be supported at the II- 
NNI. 

As a network option, in case of expiry of the CW timer, the response code 480 (Temporarily Unavailable) including a 
Reason header field set to cause 19 shall be supported at the non-roaming II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

12.8 Communication HOLD (HOLD) 

Service specific requirements in accordance with 3GPP TS 24.610 [36] shall be supported over the II-NNI. 

NOTE: The support of an alternative method not adopted in 3GPP TS 24.610 requires bilateral agreement 
between the operators and is outside the scope of the present document. 

Procedures as described in subclause 12.21.3 are used to provide announcements. 

12.9 IVIessage Waiting Indication (IVIWI) 

Service specific requirements in accordance with 3GPP TS 24.606 [1 12] shall be supported over the II-NNI. 

The SUBSCRIBE request with the event package name "message-summary" and NOTIFY request procedures 
according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI. 

The "simple-message-summary-Hxml" body described in 3GPP TS 24.606 [112] in the NOTIFY request shall be 
supported at the roaming 11-NNI. 

12.10 Communication Barring (CB) 
12.10.1 Incoming Communication Barring (ICB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header as described in 3GPP TS 24.61 1 [1 14] shall be supported at 
the II-NNI. 

The BYE request including a Reason header as described in 3GPP TS 24.61 1 [1 14] shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 
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12.10.2 Outgoing Communication Barring (OCB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header as described in 3GPP TS 24.61 1 [1 14] shall be supported at 
the roaming 11-NNl. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

1 2. 11 Completion of Communications to Busy Subscriber (CCBS) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 486 (Busy Here) containing a Call-Info header field with a "purpose" header field parameter set to 
"call-completion" shall be supported at the non-roaming 11-NNI. 

For invoking and revoking of the CCBS supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall supported at the roaming II-NNI. 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [110] should be 
supported at the roaming 11-NNl. 

NOTE: 3"* party call control procedures can be used when the REFER request is not supported at the II-NNI. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" shall be supported at the non-roaming interface II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.12 Completion of Communications by No Reply (CCNR) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 180 (Ringing) containing a Call-Info header with a purpose parameter set to 'call-completion' shall 
be supported at the non-roaming interface. 

For invoking and revoking of the CCNR supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall supported at the roaming II-NNI. 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [110] should be 
supported at the roaming II-NNI. 

NOTE: 3rd party call control procedures can be used when the REFER request is not supported at the II-NNI. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" shall be supported at the non-roaming interface 11-NNl. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 
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12.13 Explicit Communication Transfer (ECT) 

Service specific requirements in accordance with 3GPP TS 24.629 [1 16] shall be supported over the 11-NNl. 

The REFER method, the Referred-By header and the Replaces header as specified in 3GPP TS 24.629 [116] shall be 
supported at the 11-NNl for call transfer without third party call control. 

The REFER method, the Referred-By header and the Replaces header as specified in 3GPP TS 24.629 [116] shall only 
be supported at the roaming 11-NNl for call transfer with third party call control. 

12.14 Customized Alerting Tone (CAT) 

Editor's Note: To be completed 

12.15 Customized Ringing Signal (CRS) 

Service specific requirements in accordance with 3GPP TS 24.183 [98] shall be supported over the II-NNl. 

Editor's Note: To be completed when the 3GPP TS 24.183 [98] is a TSG approved document under change 
control. 

12.16 Closed User Group (CUG) 

Service specific requirements in accordance with 3GPP TS 24.654 [103] shall be supported over the 11-NNl. 

The application/vnd.etsi.cug-Hxml MIME as specified 3GPP TS 24.654 [103] shall be supported in INVITE requests at 
the 11-NNl. 

NOTE: If no agreement between the originating network and the terminating network exists to support the CUG 
supplementary service the INVITE request is rejected as described in IETF RFC 5621 [123] when the 
"handling" parameter in the Content-Disposition of the vnd.etsi.cugH-xml MIME body is set to "required". 

The 403 (Forbidden) response, the 603 (Decline) response and the 500 (Server Internal Error) response shall be 
supported at 11-NNl. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.17 Personal Network Management (PNM) 

Service specific requirements in accordance with 3GPP TS 24.259 [99] shall be supported over the 11-NNI. 

The Contact header of the REGISTER request containing g.3gpp.iari_ref feature tag with the value urn:urn-7:3gpp- 
application.ims.iari.pnm-controller shall be supported at the roaming II-NNI. 



The Accept-Contact header containing a g.3gpp.iari_ref feature with the value urn:urn-7:3gpp-application.ims.iaii.pnm- 
controUer shall be supported at the II-NNI. 

The History-Info header and Supported header containing the "histinfo" option tag as described by 3GPP TS 24.259 
[99] shall be supported at II-NNI. 

12.18 Three-Party (3PTY) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE: The requirements below can be relaxed by bilateral agreements between operators. 

The requirements for the 3PTY supplementary service are the same as for the CONE supplementary service specified in 
subclause 12.19 with the following additional requirement: 
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• A Replaces header in the header portion of the SIP URI of the Refer-to header of the REFER request shall be 
supported at II-NNI. 

12.19 Conference (CONF) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE: The requirements below can be relaxed by bilateral agreements between operators. 

The REFER request and NOTIFY request procedures according to 3GPP TS 24.229 [5] shall be supported at II-NNI. 

The application/resource-listsH-xml body shall be supported at II-NNI. 

The Referred-By header in the INVITE request shall be supported at the II-NNI. 

The "isfocus" feature parameter indicated in Contact header of the INVITE request and in the 200 (OK) response shall 
be supported at the II-NNI. 

The SUBSCRIBE request including the "conference" event package name in the Event header and the NOTIFY request 
procedures according to 3GPP TS 24.147 [106] shall be supported at the II-NNI. 

The REFER including the "method" parameter set to "BYE" according to 3GPP TS 24.147 [106] shall be supported in 
the II-NNI. 

12.20 Flexible Alerting (FA) 

Service specific requirements in accordance with 3GPP TS 24.239 [101] shall be supported over the II-NNI. 

The 486 (Busy Here) response code shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.21 Announcements 

12.21.1 General 

Announcements may be provided during the establishment of a communication session or during an established 
communication session. Both of them shall be managed over the II-NNI. 

1 2.21 .2 Providing announcements during the establishment of a 
communication session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

In case of provision of an announcement to a user over the II-NNI during the establishment of a communication, one of 
the following headers shall be supported at the II-NNI: 

the Alert-Info header in the 1 80 (Ringing) response to the INVITE request; or. 

the P-Early-Media header authorizing early media as defined in IETF RFC 5009 [12] 

NOTE: The IBCF can decide to remove the Alert-Info header if required by local policy. 

1 2.21 .3 Providing announcements during an established communication 
session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 
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In case of provision of an announcement to a user over the II-NNI during an established communication, the Call-Info 
header in a re-INVITE request should be supported at the II-NNI. 

NOTE 1 : An alternative method to provide announcements is to use the existing media stream. 

NOTE 2: The IBCF can decide to remove the Call-Info header if required by local policy. 

1 2.22 Advice of Charge (AOC) 

Service specific requirements in accordance with 3GPP TS 24.647 [122] shall be supported over the II-NNI. 

The Accept header field with "application/vnd.etsi.aocH-xml" shall be supported at the roaming II-NNI. 

The INVITE method containing application/vnd.etsi.aocH-xml MIME shall be supported at the roaming II-NNI. 

Ixx provisional responses and the 200 (OK) response to the initial INVITE request containing an 
application/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 

The INFO method containing an application/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 

The response code 504 (Server Time-out) shall be supported at the II-NNI. 

A SIP BYE request including Reason header field with a reason value with the protocol set to "SIP" and the cause set to 
"504" and a reason value with the protocol set to "Q.850" and the cause set to "31" shall be supported at the II-NNI. 

The BYE request or the final response to the BYE request including an application/vnd.etsi.aocH-xml MIME body shall 
be supported over the roaming II-NNI. 
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Annex A (informative): 
Summary of SIP headers 

A summary of the SIP headers to be used in case of interconnection by using II-NNI is proposed in Table A. 1 . 

The starting point is the sending behaviour described for proxy and UA roles in Annex A of TS 24.229 [5]. In case of 
misalignment between Table A. 1 and the behaviour described in [5], the [5] has the precedence. In case a header is not 
described in Table A. 1 and it is described in [5], description in [5] is applicable over II-NNI. 

The notation of the codes used for the SIP headers listed in table A. 1 has a different meaning to the one proposed for the 
SIP messages. The definition of these terms is provided in table A.2. 
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Table A.I : Supported headers 



Item 


Header 


Ret. 


ll-NNI 


1 


Accept 


[51 


m 


2 


Accept-Contact 


[51 


m 


3 


Accept-Encoding 


[51 


m 


4 


Accept-Language 


[51 


m 


5 


Alert- Info 


[51 





6 


Allow 


[51 


m 


7 


Allow-Events 


[51 


m 


8 


Authentication-Info 


[5] 


m 


9 


Authorization 


[51 


m 


9a 


Answer-IVIode 


[51 





10 


Call-ID 


[51 


m 


11 


Call-Info 


[51 


m 


12 


Contact 


[51 


m 


13 


Content-Disposition 


[51 


m 


14 


Content-Encoding 


[5] 


m 


15 


Content-Language 


[51 


m 


16 


Content-Length 


[51 


m 


17 


Content-Type 


[51 


m 


18 


Cseq 


[51 


m 


19 


Date 


[51 


m 


20 


Error-Info 


[51 





21 


Expires 


[51 


m 


22 


Event 


[51 


m 


23 


From 


[51 


m 


24 


Geolocation 


[51 


m 


25 


History-Info 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 4) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


26 


In-Reply-To 


[51 





27 


Join 


[51 





27a 


Max-Breadth 


[51 


n/a 


28 


IVIax-Forwards 


[51 


m 


29 


Min-Expires 


[51 


m 


30 


IVIIME-Version 


[51 


m 


31 


Min-SE 


[51 


m 


32 


Organization 


[51 


m 


33 


P-Access-Network- 1 nf o 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 2) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


33a 


P-Answer-state 


[51 





34 


P-Asserted-ldentity 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 1) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


35 


P-Asserted-Service 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 5) 


m in case of a trust relationship between the 
interconnected networks, else n/a 


35a 


P-Associated-URI 


[51 


m on roaming NNI between home and visited IIVIS, else n/a 


36 


P-Called-Party-ID 


[5] 


m on roaming NNI between home and visited IIVIS, else n/a 


37 


P-Charging-Function- 
Addresses 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 7) 


n/a 


38 


P-Charging-Vector 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 6) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


38a 


P-Debug-ld 


[51 





39 


P-Early-IVIedia 


[5] 


m 
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Item 


Header 


Ref. 


ll-NNI 


40 


P-Media-Authorization 


[5] 


n/a 


41 


P-Preferred-ldentity 


[5] 


n/a 


42 


P-Preferred-Service 


[51 


m on roaming NNI between home and visited IMS, else n/a 


43 


P-Private-Network-lndication 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 9) 


m on roaming NNI between home and visited IMS, else o 


44 


P-Profile-Key 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 8) 


on roaming NNI between home and visited IMS, else n/a 


45 


P-Served-User 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 10) 


m on roaming NNI between home and visited IMS, else n/a 


46 


P-User-Database 


[51 


n/a 


47 


P-Visited-Network-ID 


[51 


m on roaming NNI between home and visited IMS, else n/a 


47a 


Path 


[51 


m on roaming NNI between home and visited IMS, else n/a 


48 


Priority 


[5] 





48a 


Priv-Answer-Mode 


[5] 





49 


Privacy 


[51 


m 


50 


Proxy-Authentication 


[51 


m on NNI between home IMS A and home IMS B, else n/a 


51 


Proxy-Authorization 


[51 


m on NNI between home IMS A and home IMS B, else n/a 


52 


Proxy- Require 


[5] 


m 


53 


Reason 


[5] and sub- 
clause 
6.1.1.3.1 
(Table 6.2, 
item 11) 


when in a request. 

When in a response, m in case of a trust relationship 

between the interconnected networks, else n/a 


54 


Record-Route 


[5] 


m 


55 


Referred-By 


[5] 


m 


56 


Reject-Contact 


[5] 


m 


57 


Replaces 


[51 





58 


Reply-To 


[51 





59 


Request-Disposition 


[51 


m 


60 


Require 


[51 


m 


61 


Resource-Priority 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 3) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


62 


Route 


[51 


m 


63 


Security-Client 


[51 


n/a 


64 


Security-Verify 


[51 


n/a 


65 


Server 


[51 





65a 


Service-Route 


[51 


m on roaming NNI between home and visited IMS, else n/a 


66 


Session-Expires 


[51 


m 


67 


Subject 


[51 





68 


Supported 


[51 


m 


69 


Timestamp 


[51 


m 


70 


To 


[51 


m 


71 


Trigger-Consent 


[51 


m 


71a 


Unsupported 


[51 


m 


72 


User-Agent 


[51 


m 


73 


User-to-User 


[51 





74 


Via 


[51 


m 


75 


Warning 


[51 





76 


www-Authenticate 


[51 


m on roaming NNI between home and visited IMS, else n/a 
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Table A.2: Key to notation codes for SIP headers 



Notation 
code 


Meaning 


m 


The SIP header is applicable at ll-NNI. 

Supporting a SIP header at the ll-NNI means that this header is 

passed through the IBCF. It does not imply that network elements 

inside the serving and served networks or user equipment connected 

to these networks shall support this header, where 3GPP TS 24.229 [5] 

is applied. If specified in 3GPP TS 24.229, an IBCF modifies the SIP 

header. 





The applicability of SIP header at ll-NNI depends on bilateral 
agreement between the operators. 


n/a 


It is impossible to use the SIP header at the ll-NNI. This header could 
be discarded by the IBCF. 
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3 
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1 
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8.0.0 
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007 


2 
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8.0.0 


8.1.0 
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008 


4 
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8.1.0 


8.2.0 
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TSG#44 


CP-090341 


009 


4 
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8.1.0 


8.2.0 
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017 


1 
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8.2.0 
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018 


2 
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TSG#45 
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019 


1 
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020 


3 
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4 
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3 
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5 
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5 
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3 
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6 
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032 


1 
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033 


2 
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034 


1 
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035 


1 
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12/2009 
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036 


1 


Completing the Closed User Group (CUG) supplementary service 
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3 
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038 


3 
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3 
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041 


1 
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042 


3 
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2 
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3 
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1 
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4 
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